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1. Introduction 


This Request for Comments (RFC) provides information about the 
preparation of RFCs, and certain policies relating to the publication 
of RFCs. 


The RFC series of notes covers a broad range of interests. The core 
topics are the Internet and the TCP/IP protocol suite. However, any 
topic related to computer communication may be acceptable at the 
discretion of the RFC Editor. 


Memos proposed to be RFCS may be submitted by anyone. One large 
source of memos that become RFCs is the Internet Engineering Task 
Force (IETF). The IETF working groups (WGs) evolve their working 
memos (known as Internet Drafts or I-Ds) until they feel they are 
ready for publication, then the memos are reviewed by the Internet 
Engineering Steering Group (IESG), and if approved sent by the IESG 
to the RFC Editor. 


Most of the memos submitted to the RFC Editor from independent 
sources will be reviewed by the IESG for possible relationship to 
work in progress in the IETF Working Groups. 


RFCs are distributed online by being stored as public access files, 
and a short message is sent to the distribution list indicating the 


availability of the memo. 


The online files are copied by the interested people and printed or 


displayed at their site on their equipment. This means that the 
format of the online files must meet the constraints of a wide 
variety of printing and display equipment. (RFCs may also be 


returned via e-mail in response to an e-mail query, or RFCs may be 
found using information and database searching tools such as Gopher, 
Wais, or the World Wide Web (WWW). 


RFCs have been traditionally published and continue to be published 
in ASCII text. 


While the primary RFCs is always an ASCII text file, secondary or 
alternative versions of RFC may be provided in PostScript. This 
decision is motivated by the desire to include diagrams, drawings, 
and such in RFCs. PostScript documents (on paper only, so far) are 
visually more appealing and have better readability. 


PostScript was chosen for the fancy form of RFC publication over 
other possible systems (e.g., impress, interpress, oda) because of 
the perceived wide spread availability of PostScript capable 
printers. 
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However, many RFC users read the documents online and use various 
text oriented tools (e.g., emacs, grep) to search them. Often, brief 
excerpts from RFCs are included in e-mail. These practices are not 
yet practical with PostScript files. 


PostScript producing systems are less standard than is desirable and 
that several of the document production systems that claim to produce 
PostScript actually produce nonstandard results. 


In the future, it may be necessary to identify a set of document 
production systems authorized for use in production of PostScript 
RFCs, based on the reasonableness of the output files they generate. 


2. Editorial Policy 


Documents proposed to be RFCS are reviewed by the RFC Editor and 
possibly by other reviewers he selects. 


The result of the review may be to suggest to the author some 
improvements to the document before publication. 


Occasionally, it may be apparent that the topic of a proposed RFC is 
also the subject of an IETF Working Group, and that the author could 
coordinate with the working group to the advantage of both. The 
usual result of this is that a revised memo is produced as a working 
group Internet Draft and eventually emerges from the IETF process as 
a recommendation from the IESG to the RFC Editor. 


In some cases it may be determined that the submitted document is not 
appropriate material to be published as an RFC. 


In some cases it may be necessary to include in the document a 
statement based on the reviews about the ideas in the document. This 
may be done in the case that the document suggests relevant but 
inappropriate or unsafe ideas, and other situations. 


The RFC Editor may make minor changes to the document, especially in 
the areas of style and format, but on some occasions also to the 
text. Sometimes the RFC Editor will undertake to make more 
significant changes, especially when the format rules (see below) are 
not followed. However, more often the memo will be returned to the 
author for the additional work. 


Documents intended to become RFCs specifying standards track 
protocols must be approved by the IESG before being sent to the RFC 
Editor. The established procedure is that when the IESG completes 
work on a document that is to become a standards track RFC the 
communication will be from the Secretary of the IESG to the RFC 
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Editor. Generally, the documents in question are Internet Drafts. 
The communication usually cites the exact Internet Draft in question 
(by file name). The RFC Editor must assume that only that file is to 
be processed to become the RFC. If the authors have small 
corrections to the text, they should be sent to the RFC Editor 
separately (or as a "diff"), authors should not send a new version of 
the document. 


In some cases, authors prepare alternate secondary versions of RFCs 
in fancy format using PostScript. Since the ASCII text version of 
the RFC is the primary version, the PostScript version must match the 
text version. The RFC Editor must decide if the PostScript version 
is "the same as" the ASCII version before the PostScript version can 
be published. 


The effect of this is that the RFC Editor first processes the ASCII 
version of the memo through to publication as an RFC. If the author 
wishes to submit a PostScript version at that point that matches the 
ASCII version (and the RFC Editor agrees that it does), then the 
PostScript version will be installed in the RFC repositories and 
announced to the community. 


Due to various time pressures on the RFC Editorial staff, the time 
elapsed between submission and publication can vary greatly. It is 
always acceptable to query (ping) the RFC Editor about the status of 
an RFC during this time (but not more than once a week). The two 
weeks preceding an IETF meeting are generally very busy, so RFCs 
submitted shortly before an IETF meeting are most likely to be 
published after the meeting. 


3. Format Rules 


To meet the distribution constraints, the following rules are 
established for the two allowed formats for RFCs: ASCII and 
PostScript. 


The RFC Editor attempts to ensure a consistent RFC style. To do this 
the RFC Editor may choose to reformat the RFC submitted. It is much 
easier to do this if the submission matches the style of the most 
recent RFCs. Please do look at some recent RFCs and prepare yours in 
the same style. 


You must submit an editable online document to the RFC Editor. The 


RFC Editor may require or make minor changes in format or style and 
will insert the actual RFC number. 
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Most of the RFCs are processed by the RFC Editor with the unix 
"nroff" program using a very simple set of the formatting commands 
(or "requests") from the "ms" macro package (see the Appendix). Ifa 
memo submitted to be an RFC has been prepared by the author using 
nroff, it is very helpful to let the RFC Editor know that when it is 
submitted. 


3a. ASCII Format Rules 
The character codes are ASCII. 


Each page must be limited to 58 lines followed by a form feed on a 
line by itself. 


Each line must be limited to 72 characters followed by carriage 
return and line feed. 


No overstriking (or underlining) is allowed. 


These "height" and "width" constraints include any headers, 
footers, page numbers, or left side indenting. 


Do not fill the text with extra spaces to provide a straight right 
margin. 


Do not do hyphenation of words at the right margin. 


Do not use footnotes. If such notes are necessary, put them at 
the end of a section, or at the end of the document. 


Use single spaced text within a paragraph, and one blank line 
between paragraphs. 


Note that the number of pages in a document and the page numbers 
on which various sections fall will likely change with 
reformatting. Thus cross references in the text by section number 
usually are easier to keep consistent than cross references by 
page number. 


RFCs in ASCII Format may be submitted to the RFC Editor in e-mail 
messages (or as online files) in either the finished publication 
format or in nroff. If you plan to submit a document in nroff 
please consult the RFC Editor first. 
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3b. 


PostScript Format Rules 
Standard page size is 8 1/2 by 11 inches. 
Margin of 1 inch on all sides (top, bottom, left, and right). 


Main text should have a point size of no less than 10 points with 
a line spacing of 12 points. 


Footnotes and graph notations no smaller than 8 points with a line 
spacing of 9.6 points. 


Three fonts are acceptable: Helvetica, Times Roman, and Courier. 
Plus their bold-face and italic versions. These are the three 
standard fonts on most PostScript printers. 


Prepare diagrams and images based on lowest common denominator 
PostScript. Consider common PostScript printer functionality and 
memory requirements. 


The following PostScript commands should not be used: 
initgraphics, erasepage, copypage, grestoreall, initmatrix, 
initclip, banddevice, framedevice, nulldevice and renderbands. 


Note that the number of pages in a document and the page numbers 
on which various sections fall will likely differ in the ASCII and 
the PostScript versions. Thus cross references in the text by 
section number usually are easier to keep consistent than cross 
references by page number. 


These PostScript rules are likely to changed and expanded as 
experience is gained. 


RFCs in PostScript Format may be submitted to the RFC Editor in 
e-mail messages (or as online files). If you plan to submit a 
document in PostScript please consult the RFC Editor first. 


Note that since the ASCII text version of the RFC is the primary 
version, the PostScript version must match the text version. The 
RFC Editor must decide if the PostScript version is "the same as" 
the ASCII version before the PostScript version can be published. 
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4. Headers and Footers 


There is the first page heading, the running headers, and the running 
footers. 


4a. First Page 

Please see the front page of this memo for an example of the front 

page heading. On the first page there is no running header. The 

top of the first page has the following items: 

Network Working Group 
The traditional heading for the group that founded the RFC 
series. This appears on the first line on the left hand side 
of the heading. 

Request for Comments: nnnn 
Identifies this as a request for comments and specifies the 
number. Indicated on the second line on the left side. The 
actual number is filled in at the last moment before 
publication by the RFC Editor. 

Author 


The author’s name (first initial and last name only) indicated 
on the first line on the right side of the heading. 


Organization 


The author’s organization, indicated on the second line on the 
right side. 


Date 


This is the Month and Year of the RFC Publication. Indicated on 
the third line on the right side. 


Updates or Obsoletes 


If this RFC Updates or Obsoletes another RFC, this is indicated 
as third line on the left side of the heading. 
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Category 
The category of this RFC, one of: Standards Track, Best Current 
Practice, Informational, or Experimental. This is indicated on 
the third (if there is no Updates or Obsoletes indication) or 
fourth line of the left side. 


Other Numbers 


Other numbers in the RFC series of notes include the subseries 


of FYI (For Your Information) [4], BCP (Best Current Practice) 
[5], and STD (Standard) [6]. These are placed on the left 
side. 

Title 


The title appears, centered, below the rest of the heading. 
Periods or "dots" in the titles are not allowed. 


If there are multiple authors and if the multiple authors are from 
multiple organizations the right side heading may have additional 
lines to accommodate them and to associate the authors with the 
organizations properly. 


4b. Running Headers 
The running header in one line (on page 2 and all subsequent 
pages) has the RFC number on the left (RFC NNNN), the (possibly 
nshortened form) title centered, and the date (Month Year) on the 
right. 

4c. Running Footers 
The running footer in one line (on all pages) has the author’s 
last name on the left, category centered, and the page number on 
the right ([Page N]). 

5. Status Section 
Each RFC must include on its first page the "Status of this Memo" 
section which contains two elements: (1) a paragraph describing the 


type of the RFC, and (2) the distribution statement. 


The content of this section will be one of the four following 
statements. 
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Standards Track 


"This document specifies an Internet standards track protocol for 
the Internet community, and requests discussion and suggestions 
for improvements. Please refer to the current edition of the 
"Internet Official Protocol Standards" (STD 1) for the 
standardization state and status of this protocol. Distribution 
of this memo is unlimited." 


Best Current Practice 


"This document specifies an Internet Best Current Practices for 
the Internet Community, and requests discussion and suggestions 
for improvements. Distribution of this memo is unlimited." 


Experimental 


"This memo defines an Experimental Protocol for the Internet 
community. This memo does not specify an Internet standard of any 
kind. Discussion and suggestions for improvement are requested. 
Distribution of this memo is unlimited." 


Informational 


"This memo provides information for the Internet community. This 
memo does not specify an Internet standard of any kind. 
Distribution of this memo is unlimited." 


6. Copyright Notice 


Immediately following the Status section the statement, "Copyright 
(C) The Internet Society (date). All Rights Reserved." is placed. 
Also, see Section 11 for the full statement that must appear at the 
end of the document. 


7. Introduction Section 
Each RFC should have an Introduction section that (among other 
things) explains the motivation for the RFC and (if appropriate) 
describes the applicability of the protocol described. 
Normally, this will be the "abstract" section from the Internet 


Draft. If the RFC is not based on an I-D, other possibilities 
are: 
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Protocol 


This protocol is intended to provide the bla-bla service, 
and be used between clients and servers on host computers. 
Typically the clients are on workstation hosts and the 
servers on mainframe hosts. 


or 
This protocol is intended to provide the bla-bla service, 


and be used between special purpose units such as terminal 
servers or routers and a monitoring host. 


Discussion 


The purpose of this RFC is to focus discussion on particular 
problems in the Internet and possible methods of solution. 
No proposed solutions in this document are intended as 
standards for the Internet. Rather, it is hoped that a 
general consensus will emerge as to the appropriate solution 
to such problems, leading eventually to the adoption of 
standards. 


Interest 


This RFC is being distributed to members of the Internet 
community in order to solicit their reactions to the 
proposals contained in it. While the issues discussed may 
not be directly relevant to the research problems of the 
Internet, they may be interesting to a number of researchers 
and implementers. 


Status Report 


In response to the need for maintenance of current 
information about the status and progress of various 
projects in the Internet community, this RFC is issued for 
the benefit of community members. The information contained 
in this document is accurate as of the date of publication, 
but is subject to change. Subsequent RFCs will reflect such 
changes. 


These paragraphs need not be followed word for word, but the 
general intent of the RFC must be made clear. 
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8. 


10. 


Iis 


References Section 


Nearly all RFCs contain citations to other documents, and these are 


listed in a References section near the end of the RFC. There are 
many styles for references, and the RFCs have one of their own. 
Please follow the reference style used in recent RFCs. See the 


reference section of this RFC for an example. Please note that for 
protocols that have been assigned STD numbers, the STD number must be 
included in the reference. 


In many standards track documents several words are used to signify 
the requirements in the specification. These words are often 
capitalized. BCP 14, RFC 2119 [3], defines these words as they 
should be interpreted in IETF documents. 


Security Considerations Section 
All RFCs must contain a section near the end of the document that 
discusses the security considerations of the protocol or procedures 


that are the main topic of the RFC. 


Author’s Address Section 


Each RFC must have at the very end a section giving the author’s 
address, including the name and postal address, the telephone number, 
(optional: a FAX number) and the Internet email address. 


Copyright Section 


Per BCP 9, RFC 2026 [2], "The following copyright notice and 
disclaimer shall be included in all ISOC standards-related 
documentation." The following statement should be placed on the last 
page of the RFC, as the "Full Copyright Statement". 


"Copyright (C) The Internet Society (date). All Rights Reserved. 


This document and translations of it may be copied and furnished 
to others, and derivative works that comment on or otherwise 
explain it or assist in its implementation may be prepared, copied, 
published and distributed, in whole or in part, without 
restriction of any kind, provided that the above copyright notice 
and this paragraph are included on all such copies and derivative 
works. However, this document itself may not be modified in any 
way, such as by removing the copyright notice or references to the 
Internet Society or other Internet organizations, except as needed 
for the purpose of developing Internet standards in which case the 
procedures for copyrights defined in the Internet Standards 
process must be followed, or as required to translate it into 
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T2% 


languages other than English. 


The limited permissions granted above are perpetual and will not 
be revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on 
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Relation to other RFCs 


Sometimes an RFC adds information on a topic discussed in a previous 
RFC or completely replaces an earlier RFC. There are two terms used 
for these cases respectively, Updates and Obsoletes. A document that 
obsoletes an earlier document can stand on its own. A document that 
merely updates an earlier document cannot stand on its own; it is 
something that must be added to or inserted into the previously 
existing document, and has limited usefulness independently. The 
terms Supercedes and Replaces are no longer used. 


Updates 


To be used as a reference from a new item that cannot be used 
alone (i.e., one that supplements a previous document), to refer 
to the previous document. The newer publication is a part that 
will supplement or be added on to the existing document; e.g., an 
addendum, or separate, extra information that is to be added to 
the original document. 


Obsoletes 


To be used to refer to an earlier document that is replaced by 
this document. This document contains either revised information, 
or else all of the same information plus some new information, 
however extensive or brief that new information is; i.e., this 
document can be used alone, without reference to the older 
document. 
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13, 


14. 


For example: 


On the Assigned Numbers RFCs the term Obsoletes should be used 
since the new document actually incorporate new information 
(however brief) into the text of existing information and is 
more up-to-date than the older document, and hence, replaces it 
and makes it Obsoletes. 


In lists of RFCs or the RFC-Index (but not on the RFCs themselves) 
the following may be used with early documents to point to later 
documents. 


Obsoleted-by 


To be used to refer to the newer document(s) that replaces the 
older document. 


Updated-by 


To be used to refer to the newer section(s) which are to be added 
to the existing, still used, document. 


Protocol Standards Process 


See the current "Internet Official Protocol Standards" (STD 1) memo 
for the definitive statement on protocol standards and their 
publication [1]. 


The established procedure is that when the IESG completes work on a 
document that is to become a standards track RFC the communication 
will be from the Secretary of the IESG to the RFC Editor. Generally, 
the documents in question are Internet Drafts. The communication 
usually cites the exact Internet Draft (by file name) in question. 
The RFC Editor must assume that only that file is to be processed to 
become the RFC. If the authors have small corrections to the text, 
they should be sent to the RFC Editor separately (or as a "diff"), do 
not send a new version of the document. 


Contact 
To contact the RFC Editor send an email message to: 


"rfc-editor@isi.edu". 
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15. Distribution Lists 
The RFC announcements are distributed via two mailing lists: the 
"TETF-Announce" list, and the "REC-DIST" list. You don’t want to be 
on both lists. 


To join (or quit) the IETF-Announce list send a message to ietf- 
request@ietf.org. 


To join (or quit) the RFC-DIST list send a message to rfc-dist- 
request@isi.edu. 


16. RFC Index 
Several organizations maintain RFC Index files, generally using the 
file name "rfc-index.txt". The contents of such a file copied from 
one site may not be identical to that copied from another site. 

17. Security Considerations 
This RFC raises no security issues (however, see Section 9). 
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20. Appendix - RFC "nroff macros" 


Generally, we use the very simplest nroff features. We use the "ms" 
macros. So, "nroff -ms input-file > output-file". However, we could 
not get nroff to do the right thing about putting a form feed after 
the last visible line on a page and no extra line feeds before the 
first visible line of the next page. We want: 


last visible line on page i 
SE 
first visible line on page i+1 


So, we invented a hack to fix this. We use a perl script called 
"fix.p1". So the command to process the file becomes: 


nroff -ms input-file | fix.pl > output-file 


The actual perl script is: 


#! /local/bin/perl 
fix.pl 17-Nov-93 Craig Milo Rogers at USC/ISI 


The style guide for RFCs calls for pages to be delimited by the 
sequence <last-non-blank-line><formfeed-line><first-non-blank-line>. 
Unfortunately, NROFF is reluctant to produce output that conforms to 
this convention. This script fixes RFC-style documents by searching 
for the token "FORMFEED[Page", replacing "FORMFEED" with spaces, 
appending a formfeed line, and deleting white space up to the next 
non-white space character. 


There is one difference between this script’s output and that of 
the "fix.sh" and "pg" programs it replaces: this script includes a 
newline after the formfeed after the last page in a file, whereas the 
earlier programs left a bare formfeed as the last character in the 
file. To obtain bare formfeeds, uncomment the second substitution 
command below. To strip the final formfeed, uncomment the third 
substitution command below. 


This script is intended to run as a filter, as in: 
nroff -ms input-file | fix.pl > output-file 


When porting this script, please observe the following points: 


Se Se de SOS OE de ROSE OSE SER SR SR Sk SR SR SR Sk GE SR Sk Se GE SR te 


1) ISI keeps perl in "/local/bin/perl"; your system may keep it 


Postel & Reynolds Informational [Page 16] 


RFC 2223 Instructions to RFC Authors October 1997 


# elsewhere. 
# 2) On systems with a CRLF end-of-line convention, the "\n"s below 
# may have to be replaced with "\r\n"s. 
s* = 45 # Enable multiline patterns. 
undef $/; # Read whole files in a single 
# gulp. 
while (<>) { # Read the entire input file. 
s/FORMFEED (\ [Page\s+\d+\]) \st+/ \1\n\£\n/g; 
# Rewrite the end-of-pages. 
$ s/\f\nS$/\f£/; # Want bare formfeed at end? 
# s/\f\nS//; # Want no formfeed at end? 
print; # Print the resultant file. 


This script can also be copied from: ftp://ftp.isi.edu/in-notes/rfc- 
editor/fix.pl 


Now as to the nroff features we actually use, following is a sample 
memo, prepared in RFC style. 
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.nr LL 7.2i 

¿YE LT 721 

.ds LF Waitzman 

-ds RF PUTEFFHERE [Page $] 


-ds LH RFC 1149 
-ds RH 1 April 1990 
-ds CH IP Datagrams on Avian Carriers 


hy 0 
ad 1 
-in 0 
Network Working Group D. Waitzman 
Request for Comments: 1149 BBN STC 
1 April 1990 
. Ce 


A Standard for the Transmission of IP Datagrams on Avian Carriers 


¿E1L.:0 
Status of this Memo 


SEL 

«in 3 

This memo describes an experimental method for the encapsulation of IP 
datagrams in avian carriers. This specification is primarily useful 

in Metropolitan Area Networks. This is an experimental, not recommended 
standard. Distribution of this memo is unlimited. 


sti <0 
Overview and Rational 


Avian carriers can provide high delay, low throughput, and low 
altitude service. The connection topology is limited to a single 
point-to-point path for each carrier, used with standard carriers, but 
many carriers can be used without significant interference with each 
other, outside of early spring. This is because of the 3D ether space 
available to the carriers, in contrast to the 1D ether used by 
IEEE802.3. The carriers have an intrinsic collision avoidance system, 
which increases availability. Unlike some network technologies, such 
as packet radio, communication is not limited to line-of-sight 
distance. Connection oriented service is available in some cities, 
usually based upon a central hub topology. 
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.ti 0 
Frame Format 


The IP datagram is printed, on a small scroll of paper, in 
hexadecimal, with each octet separated by whitestuff and blackstuff. 
The scroll of paper is wrapped around one leg of the avian carrier. 
A band of duct tape is used to secure the datagram's edges. The 
bandwidth is limited to the leg length. The MTU is variable, and 
paradoxically, generally increases with increased carrier age. A 
typical MTU is 256 milligrams. Some datagram padding may be needed. 


Upon receipt, the duct tape is removed and the paper copy of the 
datagram is optically scanned into a electronically transmittable 
form. 


.ti 0 
Discussion 


Multiple types of service can be provided with a prioritized pecking 
order. An additional property is built-in worm detection and 


1997 


eradication. Because IP only guarantees best effort delivery, loss of 


a Carrier can be tolerated. With time, the carriers are 
self-regenerating. While broadcasting is not specified, storms can 
cause data loss. There is persistent delivery retry, until the 
carrier drops. Audit trails are automatically generated, and can 
often be found on logs and cable trays. 


-ti 0 
Security Considerations 


«in 3 

Security is not generally a problem in normal operation, but special 
measures must be taken (such as data encryption) when avian carriers 
are used in a tactical environment. 


.ti 0 
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Full Copyright Statement 
Copyright (C) The Internet Society (1997). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implmentation may be prepared, copied, published and 
distributed, in whole or in part, without restriction of any kind, 
provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 
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